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ABSTRACT 



The author presents a new framework for evaluating the evolutionary upgrade paths 
of command, control, and communications systems. system procurements today can 
be viewed as upgrades to existing systems. Most operational functions are 
performed today by commanders and their staffs with various levels of automated 
support. The upgrade procurements are intended to increase or improve this automated 
support. The author examines the shrinking budget, technology initiatives. Evolutionary 
Acquisition, Commercial-Off-The-Shelf (COTS), Non-Developmental-Items (NDI), and 
emerging open architecture standards. Current evaluation frameworks, the Mission- 
Oriented Approach (MOA), the Modular Command and Control Evaluation Structure 
(MCES), and a Cost and Operational Effectiveness Anaylsis (COE A), are examined. An 
illustration of the framework uses the United States Marine Corps’ Tactical Combat 
Operations (TCO) System. Conclusions stress that C^ systems can be viewed as 
evolutionary upgrade paths that change over time, that effective evaluations of 
evolutionary C^ systems must consider the temporal component, and that a framework, 
such as the one presented in this thesis, is needed for comparing alternative upgrade 
paths rather than alternative static C^ systems. 
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I. INTRODUCTION 



A. PURPOSE OF THESIS 

The purpose of this thesis is to present a new framework for evaluating alternative 
evolutionary upgrade paths for command, control, and communications systems. 
Unprecedented changes in the international strategic environment, coupled with 
increasing domestic budgetary pressures, necessitated a shift in US defense strategy and 
are reflected in the new national military strategy published in January 1992. The new 
strategy shifts its focus from containing communism and deterring Soviet aggression to 
a more flexible, regionally oriented strategy capable of countering a wide range of 
potential threats to vital US interests. [Ref. l;p. II-l] Guidance on changing C* systems 
and objectives have lead to initiatives such as C*! for Warrior, the Navy’s Copernicus 
concept, and the Navy and Marine Corp’s "...From the Sea" strategy. Specifically, in 
the area of acquisitions, the use of an evolutionary type acquisition concept for the 
acquisition of new C^ systems is now mandated by DoD [Ref. 2:p. 5-A-5]. 

Most C^ systems that are procured today and in the future will undoubtedly 
incorporate incremental evolutionary upgrades during their useful life cycle. The author 
proposes a methodology for evaluating alternative C^ systems that considers this temporal 
component by evaluating incremental upgrade paths. 
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B. METHODOLOGY 



In order to understand the problems associated with evaluating systems, the 
major issues that effect system evaluation will be discussed. Then, the merits of some 
the current evaluation frameworks will be examined followed by the introduction of the 
new framework. To clarify the concepts introduced by the new framework, an illustrated 
example is presented using the United States Marine Corp’s Tactical Combat Operations 
(TCO) system. 

A major issue the new framework will address is the difficult, but ever present, 
temporal component of systems. The author proposes that effective evaluations of 
new systems must include an evaluation of its planned upgrade path toward some goal 
or target level of functionality. 

C. SCOPE OF THESIS 

The main focus of this thesis is to present a useful framework for evaluating 
evolutionary upgrade paths of C^ systems. Only a general discussion of the important 
issues that effect evaluations will be given to characterize the evolutionary environment. 
The thesis will only address those issues that effect generic C^ systems. After the 
framework is presented, an illustration will be presented using the TCO alternative 
systems established by the Marine Corps about the time of this writing. All values and 
costs used in the illustration are chosen for illustrative purposes only due to the 
unavailability of actual values. 



2 



In order to maintain a smooth flow between the discussion of the framework in 



Chapter III and the illustration in Chapter IV, the background and history of TCO and 
the Marine Tactical Command and Control System (MTACCS) will be presented in 
Section D of this chapter. 

D. DEFEaXION 

The official Department of Defense (DoD) definition for a command, control, and 
communications system is; 

The facilities, equipment, communications, procedures, and personnel essential to 
a commander for planning, directing, and controlling operations of assigned forces 
pursuant to the missions assigned. 

A command, control, and communications (C^) system is a collection of tools the 
decision maker uses. It is a collection of facilities, equipment, communications, 
procedures, and personnel that helps the decision maker gather, process, and disseminate 
information. [Ref. 3:p. 1] With the increasing reliance on computer systems, the term 
command, control, communication, and computers (C) is also widely used. Likewise, 
O'*! and have been popular terms that highlight the contributions of intelligence and 
interoperability. 

To avoid confusion, the author will strictly use the term system . systems can 
also be viewed as a collection of tools that provide automated support to those functions 
that commanders have always performed (e.g., planning, directing and controlling his 
forces). Most operational Command, Control, and Communications (C^) functions are 
done today, but the level of automation of each function varies from system to system. 
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Upgrades to systems will either fully automate a function or provide automated 
support to the function. In either case, it will be referred to as automating the function.* 
Some functions may even stay manual. 

E. BACKGROUND AND HISTORY OF MTACCS AND TCO 

The Marine Tactical Command and Control System (MTACCS) is the Marine 
Corp’s current command and control concept and is compliant with the goals of C'*! for 
the Warrior. It stresses the integration of separate automation assisted Marine Air 
Ground Task Force (MAGTF) C^ systems which support tactical operations. MTACCS 
enhances the commander’s decision making capability and provides tools necessary for 
effective and efficient C^ on the battlefield. 

1. Background and History of MTACCS 
a. The Need 

The National Security Act of 1947 requires that the Marine Corps 
provide rapidly deployable amphibious forces for contingency missions in support of the 
national strategy. A key statutory mission of the Marine Corps is to provide MAGTFs 
for service with the fleet in the seizure or defense of advanced naval bases and for the 
conduct of such land operations as may be essential to the prosecution of a naval 
campaign. The coordination of such a large number of forces and equipment deployed 
over a wide geographic area demonstrates the requirement for an automated C^ system 
to effectively manage the assets available. [Ref. 4:p. 1] 

* These aspects will be expanded upon in Chapter III. 
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An automated system that can be used in peace as well as combat 
would facilitate the prosecution of battle and make more effective use of available 
resources. 

b. Historical Summary 

The MTACCS concept started with studies conducted during 1965 and 

1966, which resulted in the Marine Corps General Operational Requirements (GOR) No. 
CC-9, Marine Corps Tactical Command and Control Systems (MTACCS), issued in 

1967. The USMC issued the first MTACCS Master Plan in 1976 to provide policy and 
guidance for the integrated management of efforts to improve tactical C^. The last update 
of that plan was in 1981. Beginning in 1983, Headquarters Marine Corps (HQMC) 
incorporated the MTACCS Master Plan into the Marine Corps Command and Control 
Master Plan (C^MP), last revised in August of 1987. Termination of the Marine 
Integrated Fire and Air Support System (MIFASS), a cornerstone of MTACCS in the 
original concept, caused the MTACCS philosophy to enter a two year period of 
dormancy. Only nominal integration of tactical data systems occurred during that period. 
The current MTACCS program will revitalize the original concept, update it to reflect 
the current needs of the MAGTF, and bring a modem tactical C^ system to fruition. 
[Ref. 5:pp. 1-3] 

The objective of the MTACCS concept is to provide MAGTF 
commanders with an integrated set of systems which can receive, process, display, store, 
and distribute essential information. Figure 1 portrays the MTACCS concept as it is 
currently envisioned. 
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MARINE TACTICAL COMMAND AND CONTROL SYSTEM 




Figure 1: Marine Tactical Command and Control System 



2. Background and History of TCO 
a. Background 

Marine tactical commanders face unprecedented challenges in exercising 
C^ on the modem battlefield. The tempo of operations has increased, the MAGTF 
commander’s area of interest has expanded, and more data is required to support tactical 
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decision making. The ability to gather, process, and disseminate tactical information is 
critical to the operational success of the MAGTF. The Marine Corps has long- 
recognized the need for an automated system to improve these capabilities and first 
identified this requirement as General Operational Requirement Number CC-9 of 28 July 
1967. The requirement for the TCO system is documented in MNS, No. CCC 1.31A, 
approved by the Assistant Commandant of the Marine Corps and issued by the 
Commanding General, Marine Corps Combat Development Command (MCCDC), on 16 
June 1992. Technology is now available to support development of a command and 
control system that will significantly enhance the commander’s ability to plan and execute 
MAGTF operations. [Ref. 6:p. 1-1] 

b. Operational Concept 

The new approved standard general description of TCO as it is published 
in Campaign Plan 1- 93 is as follows: 

The Tactical Combat Operations (TCO) system will serve as the operations 
component to the Marine Tactical Command and Control System (MTACCS). 
TCO will use microcomputers to provide commanders the automation to receive, 
fuse, select, and display information from many sources, and disseminate selected 
information throughout the battlefield. TCO attributes include: automated message 
processing, mission planning, development and dissemination of operations orders 
and overlays, display of current friendly and enemy situations, display of tactical 
control measures, and interfaces with local and wide area networks. [Ref. 7:p. C- 
2 - 1 ] 

TCO will be employed at the Command Element of the Marine 
Expeditionary Force (MEF), the Marine Expeditionary Brigade (MEB), and the Marine 
Expeditionary Unit (MEU). All staff sections of the MAGTF command element will 
interface with TCO. The system will support MAGTF commanders and their staffs 
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down to the battalion level in the Ground Combat Element, down to the squadron level 
in the Aviation Combat Element, and down to the battalion (and possibly company) level 
in the Combat Service Support Element. The principle users of TCO will be the 
MAGTF commanders and their operations staff. Operators will be watch officers and 
trained enlisted personnel. 

The TCO system is designed to enhance the commander’s ability to focus 
on critical elements of information while making battlefield decisions. It will use state- 
of-the-art technology to provide a mobile, flexible, and reliable system that is able to 
interface with existing Marine Corps, other services, and joint systems. 

TCO will be composed of computerized workstations, connected by the 
designated Marine Corps standard local area networks (LAN) within each command post. 
These workstations will provide a graphical user interface and keyboard and/or pointing 
device; information processing and display; graphics; communications interface; and hard 
copy printout. LANs will be interconnected by wide area networks to other 
geographically dispersed command posts (CPs) via tactical communications assets. 
Separate, but reconfigurable, workstations are used for conduct of current operations and 
planning. This redundancy supports continuity of operations during CP displacement. 
[Ref 6:p. 1-5] 

3. Current Status of TCO 

The Marine Corps Combat Development Command (MCCDC) Studies and 
Analysis Division is currently doing a Cost and Operational Effectiveness Analysis 
(COEA) on the selected TCO alternatives. These alternatives will provide automated 
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support for many of the functions presently handled manually in the Combat Operations 
Center. The following paragraphs outline briefly the current alternative systems being 
consi^red for fulfilling the requirements of TCO. 

a. Base Case 

This alternative would be to continue the status quo. Fleet Marine Force 
(FMF) units are currently using organic tactical communications, microcomputers, and 
the tactical digital facsimile to establish C^ networks. These locally developed networks 
partially satisfy FMF requirements for automated support of operations planning and 
execution. Applications include locally developed programs tailored to support the needs 
of individual units as well as programs distributed Marine Corps-wide. However, they 
are unique to a particular MEF. 

b. Maneuver Control System (MCS) 

Under this alternative, MCS Version 1 1 software would be modified to 
satisfy TCO requirements. MCS is a component of the Army Tactical Command and 
Control System designed to provide support for operations planning and execution. 
Version 10 of MCS is currently fielded. Version 10 provides minimum capability and 
imposes a significant logistics burden. Version 11 is being developed by LORAL under 
contract to the U.S. Army Communications-Electronics Command. MCS Version 11 
will collect, store, retrieve, process, and disseminate tactical information. A digital map 
and graphic overlay capability is provided. MCS Version 11 will operate in either a 
standalone or LAN configuration on a common set of computers from the Army Tactical 



9 



Automated Command and Control System Common Hardware and Software program. 
Communications interfaces are provided to the Army tactical communications networks, 
which include single channel radio, mobile subscriber equipment, and the Army Data 
Distribution System (EPLRS/JTIDS). 

c. Command Tactical Information System (CHS) 

Under this alternative CTIS software would be modified to meet TCO 
requirements. CTIS is a C^ system developed by and fielded within the Alaskan 
Command. CTIS currently operates in an Apple Macintosh environment and is being 
ported to a UNIX-based, open systems environment. CTIS uses commercial and tactical 
phone lines and commercial modems for data communications. CTIS provides the 
battlefield commander a tool for collecting, storing, processing, and displaying 
information. CTIS has a digital mapping and graphic overlay capability. 

d. Intelligence Analysis System (IAS) 

This alternative would satisfy TCO requirements through modification 
of the IAS. IAS is designed to support tactical intelligence collection, processing, and 
dissemination down to battalion level. The IAS is being developed by the Marine Corps 
Tactical Systems Support Activity (MCTSSA) at Camp Pendleton, California. IAS is 
currently hosted on a SPARC 2 server/workstation running a SunOS UNIX operating 
system. IAS supports generation of digital maps and overlays depicting the current 
situation. Information that can be displayed includes tactical control measures, targets, 
standard military symbology, and unit status data. IAS uses Defense Mapping Agency 
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(DMA) map products. Other capabilities include U.S. Message Text Format message 
preparation, ad hoc data base query, and generation of plans and orders. IAS Version 
1.2 is currently fielded and has been used in a Special Operations Command Exercise by 
24 MEU. Version 2.0 is scheduled for release during the second quarter FY 93 and will 
provide a substantial enhancement to IAS communications capabilities. 

e. Combat Information Processor (CIP) 

Under this alternative, the Marine Corps would continue the development 
of CIP to incorporate additional capabilities required for TCO. CIP was developed by 
the Advanced Sensors Systems Branch of the Harry Diamond Laboratories in support 
of the Amphibious Warfare Technology Directorate of Marine Corps Systems Command. 
This development was conducted as an advanced technology demonstration prototype. 
The CIP system is housed in an environmentally controlled Standard Integrated 
Command Post Shelter mounted on a M1037 High Mobility Multipurpose Wheeled 
Vehicle. The system provides situation awareness through a sophisticated digital map 
capability. 

/. Naval Tactical Command System-Afloat (NTCS-A) 

Under this alternative, the Marine Corps would extend NTCS-A to meet 
TCO requirements. NTCS-A is managed by the Space and Naval Warfare Systems 
Command and developed by the Research, Development, Testing and Evaluation 
(RDT&E) Division of the Naval Command, Control, and Ocean Surveillance Center. 
NTCS-A application programs include functional applications, such as the Joint 
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Operations Tactical System and the Naval Intelligence Processing System, incorporated 
into unified builds. NTCS-A relies on shipboard front-end processing and media access 
for local and external communications. NTCS-A can access various communications re- 
sources (AUTODIN, tactical link communications and TTY) through the communications 
server/front-end processor. The NTCS-A provides the Navy tactical commander the 
information necessary to plan and execute operations. 

g. Maestro 

Command Systems Incorporated (CSI) developed the FDS-1 TCO proto- 
type. Since that time, CSI has continued to work on automated C^ systems and is 
currently marketing a product called Maestro. Under this alternative, the Marine Corps 
would acquire the current version of Maestro and modify the software to meet the TCO 
requirements. The current version of Maestro runs on a DOS operating system. 
Maestro would have to be ported to run on the UNIX operating system using an X- 
Windows/Motif GUI. Maestro uses scanned paper maps and overlays to depict the 
current situation. Information that can be displayed includes tactical control measures, 
targets, standard military symbology, and unit status data. [Ref. 8:pp. iv-vi] 

F. OUTLINE OF CHAPTERS 
1. Chapter H. The Issues 

In this chapter, the important issues of the emerging evolutionary 
procurement environment are discussed. Issues such as current technology initiatives. 
Evolutionary Acquisition, Non-Developmental-Items (NDI), Commercial-Off-The-Shelf 
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(COTS) products, and "open system" standards are presented along with their effect on 
the procurement of systems. The Mission-Oriented Approach (MOA), the Modular 
Command and Control Evaluation Structure (MCES), and the Cost and Operational 
Effectiveness Analysis (COEA) team’s evaluation approach are presented to highlight the 
current methodologies and frameworks used to evaluate C^ systems. 

2. Chapter DI. A New Framework 

In this chapter, a new framework for evaluating evolutionary upgrade paths 
of C^ system alternatives is presented. The framework is a functionally-oriented, 
capability-based approach that is intended to be a useful step by step method that 
produces valuable information about the upgrade paths of selected alternatives. Each step 
of the framework is presented along with recommended methods and procedures for 
accomplishing each step. 

3. Chapter IV. An Illustrated Application 

In this chapter, an illustration of the framework will be done using the Marine 
Corp’s Tactical Combat Operations (TCO) system. The illustration will clarify how to 
apply the concepts and procedures of the framework. A simple step by step discussion 
of how to perform each step of the framework will be presented using subjective data do 
to the unavailability of actual data. 



13 



n. THE ISSUES 



A. INTRODUCTION 

Several recent initiatives such as DoD’s Corporate Information Management 
initiative and the Joint Chiefs of Staffs "C''I for the Warrior" plan have proposed new 
ways to do business. These initiatives serve to create a procurement environment that 
is business-driven, strategically planned, standards based, integrated, evolutionary, and 
more efficient. C^ systems procured in this environment will utilize Evolutionary 
Acquisition and incorporate Non-Developmental-Items, Commercial-Off-The-Shelf 
products, and "open systems" standards. 

In order to accurately and effectively evaluate current or future C^ systems, the 
current and future environment in which they are acquired must be understood. This 
chapter wUl discuss aspects of C^ system procurement today, the current C^ technology 
initiatives, evolutionary acquisition, and open architecture standards. Some current 
evaluation frameworks will then be discussed to highlight the methodologies in use today. 

B. SYSTEMS TODAY 

system procurements today can be viewed as upgrades to existing systems. 
Most operational functions are performed today by commanders and their staffs with 
various levels of automated support. The procurements are intended to increase or 
improve this automated support. Even large procurements that make sweeping changes 
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(e.g., new systems) will be incremental and evolutionary. Therefore, it is useful to 
explicitly embrace the evolutionary upgrade concept, and develop a framework for 
comparing alternative upgrade paths rather than alternative static systems. 

C. TECHNOLOGY INITIATIVES 
1. Current State of Technology 

America is in the midst of a technological revolution that will dramatically 
change the way companies and DoD do business. NCR Chairman and CEO Gilbert 
Williamson has said: 

"...The one constant of the information technology industry is change-rapid 
change...."^ 

This continuing changing nature of technologies will directly effect the C^ systems that 
incorporate new technologies. 

New, advanced technologies can permit significant restructuring in the way 
information is acquired, processed, and disseminated. Some functions requiring 
expensive and scarce resources can be centralized and automated to reduce required 
equipment, facilities, and skilled personnel. Reliable, wideband communications can 
enable centralized support to be rapidly provided to deployed forces. [Ref.lip. III-15] 



^ Taken from an article titled "Users Call the Shots, Says NCR CEO in Expo Keynote" in 
PC Week Magazine, 29 June 1992. 
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2. Key Technologies 

In May of 1985, the Assistant Secretary of Defense for C^I tasked the 
Defense Communications Agency^ to undertake a projection and assessment of the 
impact of technology on the future systems of the DoD. DISA published the report 
called "Report of Technology Assessment" in January, 1987. The Technology 
Assessment concluded that the DoD should exploit technological opportunities to effect 
profound improvements in future system in the following areas: 

1. To make systems "smarter"; 

2. To improve software productivity; 

3. To provide for the distribution of assets for survivability; and 

4. To cope with security vulnerabilities. 

Above all, it will require further emphasis on systems engineering and 
technology transition; and the use of technology in growing capabilities in place , in 
contrast to building turn-key systems . The report highlighted that this will require 
further R&D work in seven major technology categories: 

1. Distributed Systems. 

2. Telecommunications Technology. 

3. Command Decision Support Systems. 

4. Information Security. 

^ Now called the Defense Information Systems Agency (DISA). 
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5. Software Engineering. 

6. Artificial Intelligence. 

7. Photonics. 

The report stimulated the continuation of the technology assessment effort, 

including the conduct of additional workshops and the initiation of work on protocols and 
standards within the framework of an overall technical architecture. [Ref. 9] 

3. The Effect on systems 

Technological research will continually produce advances that will improve 
and streamline the way systems perform their mission. New advances will provide 
new capabilities that will enable current systems to provide better automated support 
to the functions it supports. As new capabilities become available, existing 
systems will incrementally add these capabilities by incorporating several upgrades during 
their useful-life cycle. This results in a temporal component that must be dealt with. 

The evolutionary acquisition concept has been recognized as the best way to 
incorporate these new technology based capabilities into existing systems. The 
following section will discuss this concept. 

D. THE EVOLUTIONARY ENVIRONMENT 

It has long been recognized that the standard DoD weapon system acquisition 
process is poorly suited to the acquisition of systems. Instead, an evolutionary 
process of "growing" a system-"build a little, test a little" -has recently been 
advocated. [Ref. 10:p. 6] The National Military Strategy Document for FY 94-99, the 
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"C'‘I for the Warrior" plan, and DoD Instruction 5000.2, "Defense Acquisition 
Management Policy and Procedures" , all mandate the use of evolutionary acquisition for 
the procurement of DoD systems. 

In the late 1980’s, General Alfred M. Gray (Commandant of the Marine Corps) put 
out initiatives to reorganize the Marine Corp’s equipment acquisition and combat 
development processes. The evolutionary acquisition approach to command and control 
was adopted. A "buUd a little, test a little, field a little" strategy was put in place. [Ref. 
11 ] 



Section 1 will describe the evolutionary acquisition concept and discuss the 
advantages of it. The advantages and disadvantages of Non-Developmental Items and 
Commercial-Off-The-Shelf products will be presented in Section 3 and Section 4 will 
discuss how Evolutionary Acquisition will effect C^ systems. 

1. Evolutionary Acquisition 

The "Evolutionary Acquisition" concept is a "build a little, test a little, field 
a little" approach using off-the-shelf equipment and software where applicable. 
Evolutionary Acquisition is defined as: 

An acquisition strategy which may be used to procure a system expected to evolve 
during development within an approved architectural framework to achieve an 
overall systems capability. An underlying factor in Evolutionary Acquisition is the 
need to field a well defined core capability quickly in response to a validated 
requirement, while planning through an incremental upgrade program to eventually 
enhance the system to provide the overall system capability. These increments are 
treated as individual acquisitions, with their scope and context being the result of 
both continuous feedback from developing and independent testing agencies and the 
user.... [Ref. 12:p. 23] 
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Evolutionary acquisition is an alternative acquisition process used to acquire 
systems that are expected to evolve during development and throughout their 
operational life. Figure 2 graphically represents the application of an evolutionary 
acquisition approach. The initial preliminary system architecture is segregated into 
planned increments. Those increments are then refined, funded, and developed in stages. 
[Ref. 13] 
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2. Advantages of Evolutionary Acquisition 

There are several reasons for choosing an evolutionary acquisition approach: 

a. Lessons Learned From Past Failures 

The Marine Corps’ attempt at the "big system approach" for acquiring 
the MIFASS'* system has failed miserably in the past at extreme cost. [Ref. 14] It was 
simply too hard to adjust requirements and specifications to keep up with both user 
demand and technology, and quickly incorporate these adjustments into a system. [Ref. 
15:p. 16] Using Evolutionary Acquisition, improvements or changes can be made at the 
next incremental upgrade and can be made easily if the original core design was built 
with the changes in mind. 

b. Lack of Complete List of Defined Requirements 

A complete list of automation or support requirements would be 
impossible to generate. The introduction of new technology and procedures makes old 
tasks easier and opens the door to provide new capabilities. This makes it difficult to 
predict the final requirements. [Ref. 15:p. 16] By using Evolutionary Acquisition, the 
user can provide timely, accurate feedback of what he/she wants, needs, and actually 
uses. This feedback can be applied to the next increment and tested. 



* MIFASS was a subsystem program under MTACCS which failed for several reasons in 
1987. A comprehensive discussion of MIFASS can be found in Chapter II of Reference 14. 
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c. Political Acceptance of Evolutionary Acquisition 

The use of Evolutionary Acquisition as an alternative acquisition strategy 
is consistent with the guidance of the Office of Management and Budget Circular A- 109, 
DoD Directive 5000.1, and with Defense Acquisition Circular 76-43. Evolutionary 
Acquisition encourages regular and continual interaction with the Deputy Program 
Managers^, requirements proponents, users, developers, testers, and logisticians. It 
encourages the consideration of Non-Developmental-Items (NDI) and Commercial-Off- 
the-Self (COTS) material where applicable. [Ref. 15:p. 16] By this continual 
interaction, the risk of spending a large amount of resources with no measurable return 
is reduced. The program is reviewed by all concerned at each increment. Those 
responsible for certain fields will have to interact repeatedly with those responsible for 
the other fields that effect them. 

d. User Response is Quickly Incorporated 

By starting with equipment and procedures the user is already familiar 
with, and incorporating a limited amount of change at each increment, the user can easily 
assimilate and evaluate the change, providing appropriate and accurate feedback. 

e. Capabilities are Fielded Faster 

Evolutionary Acquisition permits faster fielding of core capabilities to 
the user. It allows building on existing equipment and systems to quickly field a useful 
core capability and concurrently develop component systems, capitalizing on the ability 

^ Deputy Program Managers are responsible for subsystems of a major acquisition program. 

They report to the Program Manager (PM). 
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to incorporate component systems as they complete their individual development phases. 
This permits new technology to reach the user at a rate that is much faster than currently 
possible. 

3. Non-Developmental Items and Commercial-Off-The-Shelf Products 

Non-Developmental Items and Commercial-Off-the-Shelfproducts are generic 
terms that describe material available from a variety of sources with little or no 
development be the government. These are items that are either available in the 
commercial market place or from other services. 

According to William H. Taft IV^, "The use of Off-The-Shelf sources is a 
major initiative of the Department of Defense [Ref. 16:p. 103]. There is considerable 
motivation to pursue this element of acquisition strategy wherever possible. Non- 
Developmental Items yield several benefits: 

1. The time in development and the time to fielding is greatly reduced. 

2. User’s requirements and needs can be met and satisfied quickly. 

3. Costs for Research and Development are reduced. 

4. Current, state of the are technology is used and fielded. [Ref. 17] 



^ Former Deputy Secretary of Defense. 
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However, there are risks involved with using Non-Developmental Items. 



These include: 



1. Cost and performance tradeoffs to accommodate the use of NDI components in 
production. 

2. The resulting proliferation of hardware and software can cause logistic support, 
training, and configuration management problems and possible increased life 
cycle costs. 

3. Safety deficiencies may occur because the NDI was not built specifically for a 
military environment. [Ref. 17] 

The benefits of using NDI should aid in the fielding of systems 
tremendously. The risks are being minimized through the use of the common hardware 
and common software. By restricting the amount and type of each, many of the 
logistical and training burdens are alleviated. 

4. The Effect on Systems 

Most systems that are procured today and in the future will undoubtedly 

incorporate incremental evolutionary upgrades during their useful life cycle. 

Evolutionary Acquisition will be the strategy used to accomplish this. Brigadier General 

Edward Hirsch’, USA (Ret.), wrote in an article in Signal magazine; 

Evolutionary Acquisition is not a cure-all for the real or perceived ills of the U. 

S. acquisition process; but it does hold some promise to help field command and 
control systems sooner, at lower cost and with higher user satisfaction than other 
approaches. [Ref. 12:p. 23] 



’ Director, Center for Acquisition Management Policy, Defense Systems Management 
College at the time of publication of the article. 
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Evolutionary Acquisition has gained wide recognition as a strategy that 
provides the flexibility necessary to adapt evolving systems. 

E. THE OPEN ARCHITECTURE ENVIRONMENT 

1. Overview 

A current approach to eliminating the problems of incompatibility, while 
transcending the problems of centralized systems, is called the "open systems" approach. 
There is a trend within the industry to develop products according to government, 
international, and industry standards. Users, vendors, and government standards 
organizations are encouraging the development of open system architectures. According 
to the International Organization for Standardization and the International Electrotechnical 
Committee (ISO/IEC), an open system is a system that complies with the requirements 
of a given set of universally accepted standards for communication and interacting with 
other open systems. Advantages of adopting open system architecture standards are the 
following: 

1. Increased competition results from the variety of vendors manufacturing 
products to meet the specified standards. 

2. Interoperability and portability are attainable only with systems using the same 
standards. 

3. Open systems support a multivendor environment, which reduces the chance that 
the government will be dependent on a single contractor. 

Although a potential logistics risk is created by a multivendor environment, this can be 
managed by requiring that all products purchased be contained on a list previously 



24 



established by the government. [Ref. 18;p. 2] The principle disadvantages of using 
standards are: 



1. A standard tends to freeze the technology. By the time a standard is developed, 
subjected to review and compromise, and promulgated, more efficient 
techniques are possible. 

2. There are multiple standards for the same thing. This is not a disadvantage of 
standards per se, but of the way things are currently done. Fortunately, in 
recent years, the various standards-maMng organizations have begun to 
cooperate more closely. Nevertheless, there are still areas where multiple 
conflicting standards exist. [Ref. 19:p. 18] 



2. The Effect on Systems 

Currently evolving open system standards include POSIX* interfaces, 
GOSIP’ data communication protocols, the ADA programming language, SQL data 
management systems, X-Windows User interfaces. Motif Graphic services, and X.400 
message handling systems. [Ref. 8:p. 3-61] Since these standards are still evolving, 
systems developed in an open systems architecture today should have an integration plan 
that allows for the smooth incorporation of future evolving standards. 

The use of open systems standards such as GOSIP is now a federal 
information -processing standard (FIPS) and is mandatory for use on government 
procurements [Ref. 19:p. 27]. systems that are developed using open system 
architectures reduce system integration costs; increase freedom of choice in selecting 



* Portable Operating System Interface; X denotes its UNIX origin. 
’ Government Open System Interconnection Profile. 
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vendors; protect investments in software, data, and people; and enhance availability, 
quality, and variety of complementary products. [Ref. 20] 

F. CURRENT SYSTEM EVALUATION FRAMEWORKS 

This section will discuss some of current frameworks used today for evaluating 
systems. 

1. The Mission-Oriented Approach (MO A) 

The Mission-Oriented Approach is a framework for formulating requirements 
in order to achieve the desired balance among mission support, technical capability, and 
resources. This approach systemically and consistently addresses four interrelated 
questions (see Figure 3). 

First, it addresses the question "What are we trying to achieve operationally?" 
This question must be answered by high-level decision makers in the context of relevant 
policy and political-military considerations. The response is generally cast in terms of 
a set of strategic capability objectives for employing forces. These force capability 
objectives provide the standards against which the capabilities of existing and proposed 
packages of information systems can be measured. 

The second phase of the requirements process addresses the question: "How 
should we perform the mission operationally?" This question must be addressed by 
operational personnel who must formulate concepts of operations at multiple levels: 
strategic (e.g., the concept of forward defense), operational (e.g., mix and emphasis 
among missions), and functional capability (e.g., ability to sense, assess, plan, and direct 
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to achieve mission goals). The capability objectives for each of these levels must be 
derived self-consistently, beginning with specified strategic capability levels, based on 
likely adversarial operations, friendly concepts of operation, and environmental factors. 

The third phase of the requirements process addresses the question: "What 
technical capability is needed to support the operation?" This phase should employ 
technical personnel to translate the operational capability objective levels into the desired 
technical attributes of the information systems needed to implement those capability 
levels. These technical capability objectives are derived using the existing and projected 
technical characteristics of adversary forces, friendly forces, and environmental factors. 

The fourth phase of the requirements process addresses the question: "How 
is the technical job to be accomplished?" As a foundation for this question, technical 
deviations are identified be comparing the technical capabilities of existing and 
programmed information systems to the time varying technical capability objectives 
identified in the prior phase. Based on those deviations, technical and programmatic 
personnel can formulate technical requirements that are consistent with assumptions on 
available resources and schedule. If these communities are to perform this task credibly, 
it is critical that they be cognizant of the unique characteristics of information systems. 
These systems are characterized by internal and external interfaces that are complex, 
frequently changing, and at multiple organizational levels. Humans are integral parts of 
these systems and their interfaces with one another and the machines are highly 
interactive, complex, and changing. The technology that underlies these systems (e.g., 
computers, communications, displays) is undergoing revolutionary change and emerging 
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systems are very software intensive. Thus the technical and programmatic communities 
face the challenging task of formulating technical requirements that balance technological 
risk and obsolescence. [Ref. 21:pp. 119-128] 

After initial answers to these four questions have been developed it is 
important to iterate through the framework. This iteration is needed to identify and 
resolve issues that require additional analysis across communities (e.g., interaction 
between the operational and technical communities) and within communities (e.g., 
technical tradeoffs between risk and potential obsolescence). [Ref. 22:pp. 2-5] 

The Mission-Oriented Approach is an attractive candidate for formulating 
system requirements in an evolutionary environment. A variation of this approach has 
been successfully used by U.S. Pacific Command (USPACOM) to help identify and 
define C^I capabilities and systems that their warfighters need to meet USPACOM 
mission responsibilities. [Ref. 23] 

While the Mission-Oriented Approach is well suited for requirements 
determination, it is not particularly well suited for the evaluation of alternative C^ 
systems, which is the focus of this thesis. But, the approach could be used to verify or 
validate current and future C^ system requirements. 

2. The Modular Command and Control Evaluation Structure (MCES) 

The Modular Command and Control Evaluation Structure (MCES) is a 
general approach to evaluating C^ systems which has been successfully applied to a 
number of issues concerning C^ system planning, acquisition, testing and operation. [Ref. 
24] It augments traditional analysis by providing a series of seven steps or modules to 
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evaluate alternative systems and architectures. These modules guide analysts who 
might otherwise focus prematurely on the quantitative model rather than the problem 
definition and the specific measures needed to discriminate between alternatives. The 
seven steps of the MCES are briefly described below including the product of each 
module. 

The MCES begins by identifying the objective of a particular application. 
This leads to a formal problem statement. The second step is to bound the system 
involved, by producing a complete list of system elements at several levels. The third 
step is building a dynamic framework that identifies the relevant process-a set of 
functions. The fourth step combines the results of steps two and three by integrating the 
system elements and the process functions into a model or representation of the 
system. The product of this module is at least a complete descriptive conceptual model 
and sometimes a complete mathematical model. The next (fifth) step is to specifically 
identify measures of performance, effectiveness and force effectiveness at the 
corresponding levels of the system and function. The sixth step is to generate results 
or values for these measures by testing, simulation, computational modeling or subjective 
evaluation. Finally, the various measures are aggregated and interpreted in the last step. 
The seven steps of the MCES are performed iteratively with the decision maker as shown 
in Figure 4. 

In an area such as C^, standard language and paradigms are difficult but 
necessary. The MCES was developed by a team of experts from industry, government 
and academia and was endorsed by the Military Operations Research Society. It presents 
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Figure 4: Modular Command and Control Evaluation Structure 



difficult concepts in a standardized way that is easily absorbed by both new practitioners 
and managers. MCES has potential for reducing mis-understandings of the purpose and 
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mis-applicability of analytical results. This is important when issues of great diversity 
of nature, size and level of detail are being considered. Standardization of analytical 
procedure can be advantageous if based on a comprehensive and rigorous methodology 
such as MCES. The MCES can be used for studies ranging from the quick conceptual 
level to the complete quantitative study. [Ref. 25:pp. 1-3] 

The MCES offers a comprehensive framework for developing robust 
measures for complex systems, but it doesn’t provide specific guidance on evaluating 
systems that will change over time. An interesting similarity exists between the Mission- 
Oriented Approach and the Modular Command and Control Structure. Note that the first 
two questions of the MOA and module three of the MCES both deal with C? functions. 
Also, the second two questions of the MOA and module four of the MCES deal with C? 
components or capabilities to support those C^ functions. 

3. The Current COEA Evaluation Framework 

The following sections will present the methodology used by the Cost and 
Operational Effectiveness Analysis (COEA) team for the evaluation of the Marine Corp’s 
TCO program discussed in Chapter I. 

a. Approach 

Each alternative was evaluated in three areas: effectiveness, cost, and 
risk. The effectiveness evaluation was conducted by an evaluation team exercising each 
of the alternative systems in a laboratory environment. The cost evaluation was 
conducted by collecting cost data from developers; the TCO program office; Marine 
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Corps Tactical Systems Support Activity (MCTSSA); Marine Corps Logistics Base, 
Albany; the MTACCS Common Application Support Software program and MTACCS 
Common Hardware Support programs; Marine Corps Operational Test and Evaluation 
Activity; civilian vendors; and the Marine Corps Cost Factors Manual. This data was 
validated and expanded using the Constructive Cost Model and the Conversion Cost 
Model. Both of these models predict software development costs based on system size 
and complexity. The Conversion Cost Model specifically addresses costs associated with 
software conversion. Discounted life cycle costs were estimated using the Marine Corps 
Summary Version Life Cycle Cost Model. The risk assessment assessed the technical 
and program risk associated with modifying each of the alternatives to satisfy the TCO 
requirement. 

b. Effectiveness Analysis 

Evaluation of the effectiveness of TCO alternatives focused on 
determining the operational effectiveness, the operational suitability, and the life cycle 
supportability of each alternative. To this end, measures were developed to support 
assessments of capability in each of these three areas. Measures of operational 
effectiveness assess the military utility of each alternative. Measures of operational 
suitability assess how well each alternative would operate in an austere environment 
without adversely impacting mobility, maneuverability, or operational flexibility. 
Measures of life cycle supportability assess sustainability, maintainability, and growth 
potential. These measures were based upon the TCO requirement as documented in the 
TCO MNS. Overall rankings were assigned. 
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c. Cost Analysis 

Life cycle cost estimates were developed for each TCO alternative. 
These show the costs to satisfy TCO core requirements and the incremental cost to satisfy 
follow-on requirements. Life cycle costs include research, development, testing, and 
evaluation (RDT&E); procurement; and 15 years of operations and support (O&S). 
RDT&E costs are associated with software development, operational test and evaluation, 
system integration and assembly, and program management. Procurement costs include 
hardware, spares, and repair parts, commercial software, contractor-provided training, 
and first destination transportation. Operations and support costs include software and 
hardware maintenance, operator training, and secondary destination transportation. 
Estimates were based on implementation of MCHS Class B hardware and MCASS 
software. An additional $1,500,000 per year has been estimated to support evolutionary, 
system improvements. The core, follow-on, evolutionary and total life cycle costs for 
each TCO alternative were calculated. All costs are in FY 93 constant budget dollars. 

d. Risk Analysis 

The TCO MNS defines a two component requirement. One component 
of the requirement is for automated tools to support operations planning and execution. 
The other component is for connectivity across the battlefield using tactical 
communications and for interoperability with other C^ systems. These two components 
are interdependent, and each must be met to satisfy the TCO MNS. Since 
communications connectivity and interoperability will be provided through use of 
MCASS modules (and the Tactical Network Server (TNS)/Tactical Communications 



34 



Interface Module (TCIM)), the risk associated with satisfying the connectivity and 
interoperability portion of the requirement is consistent across alternatives. The risk 
associated with providing the required automated support for operations planning and 
execution varies by alternative. The total risk associated with any alternative is a 
function of the program risk that an individual alternative can not provide the required 
automated tools and the risk that MCASS modules will not provide the required 
connectivity and interoperability. The total risk function is defined as the maximum of 
the program risk and the MCASS risk. 

e. Trade-Offs 

The analysis team then performs a trade-off analysis between the base 
case and the TCO COEA alternatives by analyzing the capability rankings of each 
alternative in terms of operational effectiveness, operational suitability, and life cycle 
supportability; life cycle costs; and the risk assessment. 

f. Decision Criteria 

Alternative selection is based on system capability (operational 
effectiveness, operational suitability, and life cycle supportability); life cycle cost; and 
program risk. 

g. Recommendations 

The decision criteria will then lead to recommendations^®. 



The actual recommendations of the COEA team were not officially published at the time 
of this writing and are outside of the scope of this thesis. 
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The methodology used by the COEA team is a comprehensive and 
effective way to evaluate alternative systems. It involves evaluating the alternatives 
based on their current configurations. Projected costs of adding some of the required 
core capabilities to the alternatives were computed and used in the evaluation, but 
planned upgrade paths of the alternatives were not considered in the analysis. 

G. CONCLUSIONS 

This chapter presented a discussion of the technology initiatives that will impact C^ 
systems. The Evolutionary Acquisition concept was introduced and topics such as Non- 
Developmental-Items, Commercial-Off-the-Shelf products, and open architecture 
standards were presented. A representative sample of some current evaluation 
frameworks were then discussed. 

It is important that the procurement environment for C^ systems be understood by 
the evaluators. Important factors of the procurement environment that effect C? systems 
include; the recent increased rate of technological change, the mandated use of the 
Evolutionary Acquisition concept, the use of NDI and COTS products, and the evolving 
open architecture standards. The following conclusions can be made in regard to the 
environment in which system are procured: 

1. That systems must capitalize on emerging technologies to remain mission 
capable. 

2. That systems will incorporate evolutionary upgrades throughout their useful 
life cycle. 
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3. That most of these evolutionary upgrades will be composed of NDI or COTS 
products that adhere to "open system" standards. 

The Mission-Oriented Approach, the Modular Command and Control Evaluation 
Structure, and the COEA team’s evaluation approach represent the current state of C^ 
systems evaluation. It can be concluded that none of these frameworks or methodologies 
specifically deal with the temporal component of C^ systems. One of the most difficult 
aspects of C^ systems is that they will continually change over time (given evolving 
technologies, standards and applications). No framework currently exists that specifically 
deals with evaluating the upgrade paths of C^ systems. 

As discussed, C^ system procurements today can be viewed as upgrades to existing 
C^ systems. Even large procurements that make sweeping changes will be incremental 
and evolutionary. Therefore, it is useful to explicitly embrace the evolutionary upgrade 
concept, and develop a framework for comparing alternative upgrade paths rather than 
alternative static systems. The following chapter presents such a framework. 
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m. A NEW FRAMEWORK 



A. INTRODUCTION 

1. Purpose of this Chapter 

The purpose of this chapter is to present a useful framework for evaluating 
evolutionary upgrade paths of C^ systems. As discussed, most C^ system procurements 
will be evolutionary, and both existing and new C^ systems will go through many 
changes during their useful life cycle. As emerging technologies mature, C^ systems will 
be incrementally upgraded as soon as is feasible in order to remain as mission capable 
as possible. Procurement alternatives that capture this temporal effect are evolutionary 
upgrade paths. 

The framework presented here is a functionally-oriented, capability-based 
approach intended to be a useful step by step method that produces information about 
alternative evolutionary upgrade paths that is useful to decision makers. The level of 
discussion is at a generic and sometimes abstract level so that wide applicability can be 
maintained. 

2. The Need for Effective Evaluation 

The procurement of an extensive C^ system or an extensive upgrade to an 
existing C^ system is an expensive proposition. A bad decision now could cost millions 
of dollars in the future, therefore, a thorough and effective evaluation framework is 
needed. Chapter II highlighted the major issues that effect systems and their 
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evaluation. It can be seen that just about all new systems will be procured over time, 
and will employ incremental evolutionary upgrades to keep up with technology. This 
temporal component of systems is a difficult aspect to evaluate. There are currently 
no widely accepted methods that accurately evaluate systems based on their upgrade 
paths. This framework will mainly focus on this temporal component and present a set 
of procedures for evaluating systems by viewing them as evolutionary paths toward 
some future goal or target system. 

3. Methodology 

In presenting the framework, some key terms used in the explanation of the 
framework will first be defined. Then, a step by step generic procedure will be 
presented along with recommendations on the preferred methods for accomplishing those 
steps. The methods developed in this framework are suited for use with virtually any 
system or subsystem. 

B. THE FRAMEWORK 

In presenting the framework, several terms are used that require definitions so that 
the concepts presented can be understood by the reader. 

1. Definitions 
a. System 

A system is a collection of equipment, personnel, procedures, 
facilities, and communications that provide a commander the tools essential for planning, 
directing, and controlling operations of his assigned forces. 
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For the purposes of this framework, systems can be viewed as a collection 

of tools that provide automated support to those functions that commanders have always 
performed (e.g., planning, directing and controlling his forces). The focus of most 
acquisition related system evaluations are in the area of hardware and/or software 
products that provide automated support to functions that support the warfighter. 
Therefore, the evaluation problem that this framework is tailored to deals with those 
decisions regarding which hardware and/or software products to buy or invest in. 

b. Functions 

The functions that this framework will focus on are those functions 
that commanders have always performed (e.g., develop an Operations Plan or 
disseminate an Operations Order). This is done so that the warfighter’s needs remain in 
focus. As discussed, systems provide automated support to functions. For the 
purpose of this discussion, when the automation of a function is referred to, it could 
either mean just automated support to that function or the full automation of that 
function. In order to identify the level of functions to be used in this framework, 
functional decompositions may be required”. 

c. Technological Capabilities 

In order to provide automated support to functions, the system must 
afford a set of capabilities that will be called technological capabilities (e.g., word 
processing capability, interoperability with another system, digital mapping, etc.). Most 

” Functional decompositions will be explained later in the chapter. 
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capabilities that new systems will possess are a product of some new technological 
advance (e.g., fiber optics, open systems standards, bubble memory, etc), therefore, they 
will refer to as technological capabilities. In order to provide automated support to a 
function, a set of technological capabilities is required. For example, to automate the 
production of overlays, technological capabilities such as pen/mouse user interface, 
digital mapping, high resolution display, iconic and symbology database, and hard copy 
capabilities are just a few of the technological capabilities required. 

d. The Target System Functions and Capabilities 

The target system is a system that provides the desired level of automated 
support to each of the functions within the system boundaries at some future planning 
horizon. 

The target system functions are the set of functions that are automated 
in the target system, and the target system capabilities are the technological capabilities 
required to provide the automated support. 

The target system functions and capabilities will be displayed in a 
function/capability table so that the relationship between them can be clearly seen. 
Figure 5 illustrates what this table will look like. For example, referring to Figure 5, 
in order to automate function FI, technological capabilities TCI and TC3 are required. 

e. Current or Base System 

A current or base system is a system that is currently in use or one that 
could be bought today. It usually only automates a subset of the functions listed in the 
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Figure 5: Capability/Function Table 



target system’s function/capability table described above. In an evaluation, current or 
base systems are viewed as alternative base systems. These alternative base systems are 
those systems that can be reasonably expected to some day obtain the level of automation 
that is required in the target system. 



/. Migratory Systems 

Migratory systems are future upgraded versions of a particular base 
system and usually consists of the base system plus some additional technological 
capabilities. Several migratory systems could spawn from a base system given different 
evolutionary upgrade plans. 
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g. Viable Upgrade Path 

A viable upgrade path is an incremental series of upgrades to a base 
system that will eventually lead to a fully functional target system. A viable path is one 
that is reasonable in terms of cost and risk and is agreed upon by the operational, 
technical, and the programmatic experts. Effective cooperation is crucial in the 
development of these viable upgrade paths. Figure 6 illustrates how each alternative base 
system could take different paths toward achieving the required target capabilities. 




Figure 6: Illustration of Viable Paths 
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h. Value 



The term value will be used to represent the benefit gained by a force 
when a particular function is provided the required level of automated support. This 
added value or benefit to the force due to the automation of a function could be 
measured in terms of a Measure of Force Effectiveness (MOFE)*^ or in terms of a 
relative importance or weight‘d. In either case, a value or benefit to the force, must be 
associated with each target system function. 

I. Costs 

Two types of costs are referred to in the discussion of the framework. 
The first type of cost focuses on procuring a particular alternative base system today. 
This cost should be an estimated life cycle cost of the alternative base system as it is 
configured today. It should include the costs associated with research, development, 
testing, and evaluation (RDT&E); procurement; and 15 years of operation and support 
(O&S)”. Costs associated with hardware procurement, hardware and software 
integration, system fielding, hardware and software maintenance, and system training and 
operations can be collected from government organizations, government publications, and 
private industry. All cost data should be normalized to the current constant budget 
dollars. 



For example, force exchange ratio, number attackers attrited per unit time, etc. 
Methods for obtaining relative weights will be discussed later. 

The 15 year life was taken from the COEA Final Report (Draft) 
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The second type of cost used in the framework is the cost of adding 
technological capabilities to alternative base systems. The same kind of life cycle costs 
as discussed above should be used, but it should focus only on the costs associated with 
a particular technological capability and its integration into an existing system. The cost 
of adding a technological capability only needs to be normalized to the year in which it 
is projected to be added to a system. Methods for discounting these costs will be 
presented later. 

2. The Framework 

In order to evaluate alternative systems that will change over time, the ideas 
of a current or base system, migratory systems, and a target system help frame the 
problem. The current system is the system currently in use or one that could be bought 
today to fulfil some mission need. All systems or subsystems in place today will some 
day either become technologically obsolete or no longer meet the needs of the user. 
When the time comes to replace or upgrade that system or subsystem, decisions must be 
made as to how to proceed. This framework presents a method that could be useful to 
decision makers in making that decision. The framework contains four top level steps: 

1. Define target system functions and capabilities. 

2. Define all viable upgrade paths from each alternative base system to the target 
system; each path becomes a candidate path. 

3. Develop a discounted value and a discounted cost for each candidate path. 

4. Select the candidate path that maximizes value subject to a stated cost, resource, 
and risk constraints. 
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A brief summary of the steps shown in Figure 7 follows. 




Figure 7: The Steps of the New Framework 

The first step of the framework begins by defining the target system in terms 
of the functions it should automate and the technological capabilities required to automate 
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each of those functions. The value of each of those functions is then determined. The 



output of this step is a table highlighting the relationships between the target system’s 
technological capabilities and the functions it must automate along with the value of each 
function. The second step of the framework begins by identifying all of the alternative 
base systems in terms of the technological capabilities they possess. All viable paths to 
the target system that spawn from each alternative are then determined. The output of 
this step is an enumeration of all viable candidate paths. The third stq> of the framework 
involves assigning functionally derived values and capability derived costs to each 
candidate path at discrete time intervals. These values and costs are then discounted to 
the present. The output of this step is a discounted value and cost associated with each 
candidate path. The last step of the framework involves filtering out the candidate paths 
that do not meet the cost constraint and then picking the candidate path that has the 
greatest value. This should result in the candidate path that provides the greatest value 
to the force given a particular cost constraint. 

The above steps of the framework are expanded upon in the following 

sections. 

a. Define Target System Functions and Capabilities 
Figure 8 illustrates this step. 

(1) Functions and Capabilities. In the acquisition world, descriptions 
of target systems are easily found in documents like the Mission Need Statement (MNS) 
and the Operational Requirements Document (ORD). These documents highlight needs, 



47 




Figure 8: The New Framework - Step 1: Define Target System 



requirements, and constraints for a given system. In the case of systems, from the 
requirements, a list of functions that require automated support can be derived. This 
automated support is provided via capabilities. The functions derived from the 
requirements are normally those that commanders and their staffs have always done 
(e.g., prepare an operations order and disseminate it, develop courses of action, decide 
on course of action, direct his forces, etc.). The functions*^ should be chosen at a level 



At this point, the author will assume that the functions can be automated independently, 
realizing that interdependence really exists. 
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that will allow a manageable sized list of required technological capabilities to be 
defined. Functional decompositions are usually required. Figure 9 illustrates what a 
simple generic functional decomposition looks like. 




Figure 9: Example of Generic Functional Decomposition 



Once the functions are identified, the technological capabilities required to provide the 
required automated support can be determined. Through elicitation of technical and 
operational experts, a list of the capabilities required to automate each function at the 
required level can be obtained. It should be realized here that some of the capabilities 
in this list may not be available yet, given the current state of technology. 

After completing the above procedure, a function/capability table can be 
constructed that shows the relationships between the functions and the technological 
capabilities. Table I illustrates what this table looks like. In the column that corresponds 
to an operational function, an X is placed in the boxes corresponding to the rows of the 
technological capabilities required to automate that function. A function cannot be 
automated at the required level unless all the technological capabilities with an X in that 
function’s column are provided by the system. For example, from Table I, function FI 
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Table I: FUNCTION/CAPABILITY TABLE 



Technological 

Capabilities 


Operational Functions 


FI 


F2 


. • . 


FN 


: TCI 


X 






X 


TC2 


X 


X 




X 


. . . 










TCn 




X 







cannot be adequately supported with the desired level of automated support unless the 
system possesses technological capabilities TCI and TC2. 

(2) Value ofCf Functions. Once the relationship between target system 
functions and capabilities is known, the next part of this first step is to determine the 
value of each function. The goal here is to assign a value or benefit added to the overall 
force when a particular function is automated. 

One method to accomplish this would be to design an experiment 
or construct a model that would allow the assessment of the effect on overall force 
effectiveness given that a particular function is automated. Runs of the experiment or 
model could be made when the function is performed without automated support and 
then again with the automated support*®. The outcomes of each case could be compared 
and a MOFE assigned as the value of the function. This method would be done for all 



*® A typical question that could be answered is, "What effect does automating overlays have 
on the overall effectiveness of the force?" 
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of the target system functions. But, it obviously would require a substantial expenditure 
of time and money, both of which are usually limited. 

Another method requiring less time and money would be to elicit 
relative values*^ or the importance of each function from experienced operational 
experts. The idea is to elicit from the experienced experts the relative importance to the 
operational force of automating each target system function. Various methods of 
elicitation include closed questions, open questions, brainstorming guided brainstorming, 
and group consensus. [Ref. 26] 

Other methods such as the Analytic Hierarchy Process (AHP) or 
the Simple Multi- Attribute Rating Technique (SMART) can also provide tools to aid in 
obtaining the relative value or weight of each function to the force. [Ref. 27] These two 
methods structure the problem as a hierarchy which serves as a useful aid to 
understanding problems and fostering discussion about them. The process can reveal 
issues which have not previously been explicitly stated. AHP utilizes pair-wise 
comparisons of attributes^*, where as SMART elicited values on a 0-100 scale for each 
attribute. The process used by both is easy to understand and decision makers have been 



The term relative value or weight has, at times, not been well received by professionals 
in the acquisition and operational fields because arguments among steering committee members 
have lasted for hours on what weights to assign. This should not be viewed as bad, in fact, this 
is one of the advantages of this kind of method because it forces decision makers to deal with 
difficult issues that may have not been explicitly stated before. 

Attributes, in the case of determining relative values of functions, would refer to low 
level functions that result from the decomposition of higher level functions. 
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comfortable with it‘®. Applying either of these methods would result in a list of the 
relative values or weights for each function. These methods emphasize the point that the 
value of a system (through automation of functions) is what it does for the user. This 
value can be estimated via the user’s perception of the relative importance of the various 
areas in which the user benefits from the system. [Ref 28] 

Table n illustrates what the results of this step should produce. In 
summary, the first step of this framework results in defining the target system in terms 
of the functions it supports and the technological capabilities required to provide 
automated support to those functions. Furthermore, the value of each function is 

Table H: FUNCTION/CAPABILITY TABLE FOR THE TARGET SYSTEM 



Technological 

Capabilities 


Operational Functions 


FI VI 


F2 V2 


. . . 


FN VN 


TCI 


i X 






X i 


TC2 


X 


X 




X i 


. • • 










TCn 




X 







determined in terms of a MOFE or by a weight or relative importance to the force. 
The added VI, V2, ... , VN in Table II represent the value of that particular function. 



Case studies can be found in Reference 27. 
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This table provides the information needed in subsequent steps of the framework. The 
next step involves defining candidate paths. 

b. Define Candidate Paths 

Figure 10 illustrates this step. The step of defining candidate paths 
requires two tasks, first the alternative base systems are determined and then the 
candidate paths that spawn from these alternative base systems are enumerated. The goal 
of this step is to come up with a list of the viable (or reasonable) candidate paths that will 
lead to obtaining the capabilities established in the definition of the target system 
functions and capabilities from step one. 

This step begins by identifying the alternative base systems that will be 
considered in the evaluation. These alternatives should be systems that preferably 
already meet some of the requirements of the target system. The alternative base 
systems should be chosen by the experts with the target system in mind. The concept 
is that each chosen alternative base system could someday fulfill all the requirements of 
the target system by incrementally adding future technological capabilities. Initially, each 
alternative base system will possess a set or vector of technological capabilities, TC. 
Let time be discrete (t = 1,...,T) where T is the planning horizon, then at each date t, 
there is a vector of technological capabilities TCt generated by each alternative system. 
Each alternative system will evolve over time given that there is technological change 
over time (and hence automation opportunities). Several viable paths could spawn from 
each alternative system. Each one of these viable paths will become a candidate path and 
could be developed by creating a specific scenario of technological change and 
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DEFINE CANDIDATE PATHS 



• UST THE ALTERNATIVE SYSTEMS 

• CONSTRUCT -VIABLE" PATHS TO 

THE TARGET SYSTEM FOR EACH 
ALTERNATIVE SYSTEM 



CAMDIDATS PATES 



ALTB»UTIVEB»SE 

SYSTBAS 



TABGCTSYSrai 




Figure 10: The New Framework - Step 2: Defining Candidate Paths 



automation for its base system. Each candidate path should satisfy the current cost, 
resource, and risk constraints. 

The Figure 1 1 illustrates that each particular alternative base system will 
migrate towards the capability of the target system by following one of several reasonable 
and viable paths of upgrades. Each candidate path begins at an alternative system. As 
technological capabilities are added, migratory systems are realized until fmally the 
capabilities of the target system are obtained. At each date t, each candidate path has 
associated with it a new vector or set of technological capabilities. This list of 
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Time = T (Hanning Horizon) 



Time - 0 




capabilities may succeed in providing the capabilities required to provide automated 
support to more target system functions. Therefore, each candidate path contains a 
changing list of technological capabilities and a changing list of functions that it can 
provide the required automated support to. The next step of the framework involves 
determining the overall value and cost of each candidate path. 

c. Get Values and Costs 

Figure 12 illustrates this step. The goal of this step is to derive a single 
overall discounted value and a single overall discounted cost for each candidate path 
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constructed in step two of the framework. Methods for determining the discounted 
values and costs will be presented in the following sections. 




DEVELOP VALUE AND COST 



• EACH FUNCTION PROVIDED HAS A VALUE 

• EACH CAPABILITY HAS A COST 

• CREATE VALUE AND COST VECTORS 

FOR EACH CANDIDATE PATH 

• DISCOUNT THE VALUES AND COSTS 

• ADD ALL DISCOUNTED VALUES AND COSTS 

FOR EACH CANDIDATE PATH 



CANDIDATE PATH 




TIME = 0 


1 


2 


••• 


T 


COST CO 


C1 


C2 




CT 


VALUE VO 


V1 


V2 




VT 



OVERALL VALUE - SUMpiSC»UNTED(VO. VI VT)] 

OVERALL COST - SUM[DISCOUNTED(CO. Cl, CD) 



Figure 12: The New Framework - Step 3: Develop Value and Cost 



(1) Value. Since the value of each function defined in the target 
system is now know from step one, the overall value of any candidate path depends on 
the functions it succeeds in automating and when they are automated. Any set or vector 
of technological capabilities, TC, can be easily assigned a value by adding the values of 
the functions that the set of capabilities automates. Since each candidate path is actually 
a time series of TC vectors, at each time step there is a TCt (vector of technological 
capabilities at time t). Each successive TC, vector of a candidate path may provide the 
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capability to automate additional functions by the addition of more technological 
capabilities. So each candidate path can be viewed as a time series of upgrades 
(additional technological capabilities added) that incrementally automate additional 
functions until all the functions of the target system are given the required level of 
automation support (from the definition of the target system in step one). 

If each candidate path simply receives the value of a function when 
it succeeds in automating it, all paths will receive the same value since all candidate 



DISCOUNTING OF FUNCTIONS 




YEAR IN WHICH SYSTEM GAINS FUNCTION 



Figure 13: A Way to Discount the Value of a Function 
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paths will eventually automate all of the target system functions. Clearly, it is more 
useful to the warfighter to provide automated support today rather that several years in 
the future. Measures used to compare paths should reflect this difference. Therefore, 
in order to make this a meaningful measure, a method of discounting the value of 
functions must be used. In order to develop a discounted value for the candidate paths, 
a value versus time curve for each function is needed. It is generally agreed that the 
sooner a system can automate a particular function, the more valuable that system will 
be to the user in terms of that function. That is, a candidate path that automates a 
particular function earlier than another should receive more value for automating that 
function sooner. Therefore, for each function, a kind of "utility" curve could be 
developed like that in Figure 13^°. The lower curve could be used for functions that 
are more critical to the users. That is, if two candidate paths are being compared, the 
path that automates a function (utilizing the lower curve for its discounting) the soonest, 
will receive a far greater value than a path that automated the function later. Where as, 
if the upper curve was used, the difference in value between two paths would be less. 

For ease of calculations, the simplest case would be that at the present time (t = 0), the 
full value of a function is given if the vector of technological capabilities, TCq, present 
in the alternative base system for a candidate path has all the capabilities required to 
automate that function. If, on the other hand, the function is not automated until the 
planning horizon, say ten years (t = 10), by the vector TCio, some residual fraction 

A thorough discussion of utility theory and its relationship to decisions under risk is 
contained in Chapter 11 of Reference 29. 



58 



(one-half is chosen for the illustration) of the value to the force of automating that 
function would be given to the candidate path. 

How this "utility curve" of the value of the function in Figure 13 behaves 
between the present time and the planning horizon is a function of the temporal 
importance or the time criticality of automating that function as discussed above. 

The discounted values, denoted DV, for each function are derived 
from each function’s utility curve and are a function of the time the system received the 
capability to automate that function. The following equation would be used to calculate 
the discounted value of a function if the linear relation in Figure 13 was chosen: 



DV,=V,-t 



h 

20 



( 1 ) 



Where DV; is the discounted value of the i* function, V; is the 
value of the i* function at t = 0, and t is the year or time period that the candidate path 
successfully automates the function i. 

The overall discounted value, ODV, of a particular candidate path 
would then be the sum of the discounted values of each function^^ To find the overall 
discounted value of the candidate path, the individual discounted values of each function 
are simply added. The following equation will be used: 



Still assuming that independence exists between functions. 
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(2) 



N 

ODV='^ DVj^ 
i=l 

Where ODV is the overall discounted value of the candidate path, i is a 
counter for the individual functions, N is the total number of functions, and DVj is the 
discounted value of the i* function. 

This concept of functionally derived values can provide valuable insight into 
prioritizing the more important technological capabilities for future acquisition decisions. 
Candidate paths that receive relatively high values will undoubtedly benefit the user more 
than one with a lower value because the more important functions are automated sooner. 

(2) Cost. Costs used in this framework are derived from capabilities 
and are those discussed in Section 2, Paragraph i. They consist of the cost of the 
alternate base system if bought today and the cost of adding a particular technological 
capability in the future to a given base system. Costs of adding a particular technological 
capability may be different for each alternative base system because each system may 
require different combinations of hardware and/or software to provide the required level 
of automation depending on the current configuration of the base system. As discussed 
earlier, the costs should include the costs associated with research, development, testing, 
and evaluation (RDT&E); procurement; and 15 years of operation and support (O&S)^^. 
Costs associated with hardware procurement, hardware and software integration, system 
fielding, hardware and software maintenance, and system training and operations can be 



The 15 year O&S time frame was used in the COEA Final Report (Draft). [Ref. 8] 
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collected from government organizations, government publications, and private industry. 
The cost of the alternative base system should be normalized to the current constant 
budget dollars, but the cost of adding the technological capabilities should be normalized 
to the year in which they are added to a candidate path. 

Discounted costs of adding technological capabilities are computed 
using the standard discounting function: 



PC,= 






(3) 



. (1 

Where DCj is the discounted cost of adding the j* technological 
capability, r is the discounting factor or interest rate, y is the year or time period, and 
Cj is the cost of adding the j* technological capability to the system. 

To calculate the overall discounted cost of the candidate path, the 
initial cost of the alternative base system is added to the discounted cost of each 
technological capability that is added to the candidate path. The following equation is 
used to compute the overall discounted cost of a candidate path: 



M 

ODC^IC +Y^DCj ( 4 ) 

J = 0 

Where ODC is the overall discounted cost of a candidate path, ICj 
is the initial cost of buying the alternative base system, M is the total number of 
technological capabilities that are added to a candidate path, and DCj is the discounted 
cost of adding the j* technological capability. Figure 14 illustrates these calculations. 
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CANDIDATE PATH 



BASE SYSTEM 



MIGRATORY SYSTEMS 



TARGET SYSTEM 
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TC VECTOR FUNCTIONS 
ADDED 
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TCVBCTOR RJNCnONS 




(COST AND VALUES ARE DISCOUNTED TO THE PRESENT) 



Figure 14: The Discounting of Values and Costs 

The procedure for finding the overall discounted value and cost of a 
candidate path is straight forward. The first step involves determining when (or at which 
time periods) the candidate path will succeed in automating the functions of the target 
system. The second step requires the use of Equation (1) to compute the discounted 
value of each of the functions. The third step uses Equation (3) to calculate the 
discounted costs of the technological capabilities that are added to the system. The fourth 
and fifth steps use Equations (2) and (4) to compute the overall discounted value and cost 
of the candidate path. 
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The output of the above calculations is a single overall discounted value 
and a single overall discounted cost for each candidate path. The next step discusses how 
to select the best candidate path given this data. 

d. Select Candidate Path 

Figure 15 illustrates the final step. The above procedures will result in 
a list of the discounted values and costs for each candidate path. A simple, but common 
problem statement is to maximize value subject to cost, resource, and risk constraints. 
The rule or problem is stated as: 

Maximize: Value 

Subject to: • Cost 

• Resource 

• Risk 

This would result in the candidate path that provides the user with the best 
possible benefit within the established cost, resource, and risk thresholds. The method 
for selecting the best candidate path under this rule is to disregard the candidate paths 
that do not meet one or more of the constraints. Then select from the remaining 
candidate paths the one with the highest value. 
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Figure 15; The New Framework - Step 4: Select Best Candidate Path 



3. Conclusions 

In the above discussion, a framework for evaluating alternative evolutionary 
upgrade paths was developed. Methods for defining a target system, developing 
candidate paths, and assigning values and costs to those paths have been presented. 
These values and costs can then be compared given a set of decision criteria and the 
"best" system with its associated upgrade path can be selected. It would then be up to 
the decision makers to consider any further issues before reaching their final decision. 
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These kinds of decisions may be made many times (for each upgrade 
procurement). For each evaluation, some or all of the process will be repeated; if the 
functions to be supported have changed (which may be infrequent), the target system 
functions and capabilities could be modified, giving a new set of functions with 
associated values. In either case, technological advances will make new capabilities 
available, giving new sets of candidate paths with their associated discounted values and 
costs. 

The overall goal of evaluating alternatives is to pick the "best" alternative. 
For this framework, the "best" alternative is the system that provides us the best path 
(series of upgrades over time) to some target system by maximizing the value of the 
system (and system path) subject to cost, resource, and risk constraints. The value and 
cost of a candidate path that spawns from a base system will be measured in terms of the 
discounted cost and the discounted value of each upgrade path. This framework will help 
the decision makers by providing insightful and valuable information on the upgrade 
paths of the decision alternatives. 

4. Application of the Framework 

The above presentation was at a rather general and abstract level. The 
following chapter will provide a more concrete illustration of how this framework can 
be used to evaluate a real system, the USMC’s current TCO system. 
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VI. AN ILLUSTRATED EXAMPLE 



A. INTRODUCTION 

1. Purpose of this Chapter 

The purpose of this chapter is to provide an illustration of the framework 
described in Chapter HI. The illustration will focus on the Marine Corp’s TCO system 
described in Chapter I. The illustration should clarify how the methods discussed in the 
previous chapter can be applied. Values and costs used in the illustration are not actual 
values and are included in order to facilitate the illustration. Furthermore, only a small 
sample of the functions and technological capabilities of TCO will be used in this 
illustration. 

2. The Problem 

The problem associated with the Marine Corp’s Tactical Combat Operations 
System is a common one. Most new military C^ systems will require a Cost and 
Operational Effectiveness Analysis (COEA) to be done on the chosen alternative base 
systems. In the case of TCO, several alternative base systems were selected^. The 
TCO COEA team is currently performing an analysis on the alternatives and will 
recommend to the decision makers the alternative that best meets the needs of the Marine 
Corp’s TCO system in June 1993. 



See Chapter I for the list of alternatives. 
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While it is agreed that no system can currently satisfy all of the TCO 
requirements, the actual goal should be to pick the system that offers the "best" path 
toward achieving the Target TCO system requirements. The actual requirements for 
TCO were derived from the approved Mission Need Statement (MNS) dated 16 June 
1992 and are divided into core requirements and follow-on requirements. [Ref. 8] 

The following sections present the illustration. 

B. THE n.LUSTRATION 

1. Define Target System Functions and Capabilities 

The first step of the framework begins by defining the target TCO system 
functions and capabilities. The functions are those it must automate and the technological 
capabilities are those required to provide automated support to each of the functions. 
Values of each of the functions to the force are then estimated. The output of this step 
is a table highlighting the relationship between the target system’s technological 
capabilities and the functions it automates. 

The Target TCO System can be defined by using the core and foUow-on 
requirements found in the MNS. From this document a list of functions requiring 
automation is derived. To obtain functions that are at the appropriate level of complexity 
for use in this framework, functional decompositions are required. The functions of the 
target system should be at a level that would allow the list of technological capabilities 
required to automate that function to be a list that is manageable in size. To illustrate 
this point, let us begin with the relatively high level function of producing an operations 
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order. This function could be decomposed into many lower level functions. For the 
purposes of this illustration only a subset of these lower level functions are used. Figure 
16 illustrates the simple functional decomposition required for this example. The 
functions chosen for this illustration are the mapping function, the overlay production 
function, and the information exchange function and can be seen in Figure 16. 




Figure 16: Example of the Functional Decomposition Performed for Step 1 

Past, present, and future commanders and their staffs have performed, now 



perform, and probably will always perform these functions. The level of automated 
support will change as technologies mature. The requirement given in the MNS for TCO 
calls for these functions to be automated. The following table shows the relationship 
between these functions and their associated required technological capabilities. For the 
purpose of this illustration, the technological capabilities listed in the table are actually 
only a representative subset of the needed capabilities to provide automated support the 
these functions. The table in Figure 17 will serve as the definition of our TCO Target 
System functions and capabilities. 
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FUNCTION/CAPABILITY TABLE FOR THE TARGET TOO SYSTEM 



TECHNOLOGICAL 

CAPABILITIES 


FUNCTDNS 


Automate Mapping 


Automate Overlays 


Automate Info Exchange 


Selectable level of Map Detail 


X 


X 




Zoom-ln/Zoom-Out Capability 


X 


X 




DMA Product Compatibility 


X 




X 


Scanned Map Capability 


X 






3-D Map Capability 


X 






Generate Overlays 




X 




Disseminate Overlays 




X 


X 


3-D Overlay Capability 




X 




Large Color Print Capability 




X 




Large Screen Display 




X 




LAN Connectivity 






X 


Single Channel Radio Connectivity 






X 


Switched Backbone Connectivity 






X 



X -- Denotes that the Technological Capability is required to automate that Column s Function 



Figure 17: Function/Capability Table for the TCO Target System 

Note that even some of the technological capabilities are quite complicated. 
Further definitions of the technological capabilities are needed in order to determine 
exactly when a particular system obtains that technological capability in the future. For 
example, the technological capability of DMA product compatibility requires that the 
system has the capability to build, store, retrieve, display, and transmit a digital map 
from either a raster or vector DMA map source. [Ref. 8] 

The next part of this step involves assigning values to the functions in the 
form of MOFEs or relative weights. As discussed in Chapter III, a method needs to 
devised for obtaining a value for each function. For the purpose of the illustration the 
elicitation method will be simulated by assigning an equal weight of one (1) to each 
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function. This serves to make further calculations simpler and is a viable option for the 
evaluators if time and resources limit the construction of a model or an exercise to derive 
MOFEs or the taking of a survey. Also, if the evaluators feel that relative weights won’t 
be acceptable to the decision makers, they have the opportunity to assign their own 
weights or assign equal weights to each function. 

Now that the Target System functions and capabilities are defined and a value 
of one (1) given to each of the functions, it is time to proceed to the next step of the 
framework. 

2. Define Candidate Paths 

The second step of the framework involves identifying all of the alternative 
base systems in terms of the technological capabilities they possess. All viable paths to 
the target system functions and capabilities that spawn from each alternative are then 
determined. The output of this step is an enumeration of all candidate paths. 

With only the draft final COEA report available at the time of this writing, 
the alternative systems listed in Chapter I may not be all that the USMC will consider. 
For purposes of this illustration, candidate paths will only be enumerated for two of the 
alternative systems, the Naval Tactical Control System-Afloat (NTCS-A) and the 
Intelligence Analysis System (IAS). These two systems will become the alternative base 
systems for TCO. 

Neither alternative obtains all of the technological capabilities required to 
automate the three target system functions, but each currently possesses a subset of them 
as shown in Figures 18 and 19. Figure 18 contains a function/capability table for the 
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FUNCTION/CAPABILITY TABLE FOR NTCS-A BASE SYSTEM 



TECHNOLOGICAL 

CAPABILITIES 


FUNCTIONS 


Automate Mapping 


Automate Overlays 


Automate Info Exchange 


Selectable level of Map Detail 


00 






Zoom-ln/2oom-Out Capability 








DMA Product Compatibility 






CX) 


Scanned Map Capability 


X 






3-D Map Capability 


X 






Generate Overlays 




00 




Disseminate Overlays 






09 


3-D Overlay Capability 




X 




Large Color Print Capability 




(x) 




Large Screen Display 






1 


LAN Connectivity 






X ! 


Single Channel Radio Connectivity 






® i 


1 Switched Backbone Connectivity 






X 



X -■ Denotes that the Technological Capability is required to automate that Column s Function 
(x) Denotes that the System possesses this Technological Capability 



Figure 18: Function/Capability Table for the NTCS-A 

NTCS-A alternative base system and Figure 19 contains the function/capability table for 
the IAS alternative base system. The tables show what technological capabilities the two 
alternative base systems have today. 

The next step involves selecting the viable paths that spawn from each 
alternative that will eventually fulfill the target system’s requirements. In the case of 
NTCS-A, to provide the required automated support to the mapping function, scanned 
maps and three-dimensional maps technological capabilities are required. To meet the 
automation of overlays requirement, a three-dimensional overlay capability is required 
and to automate the information exchange function, LAN connectivity and Switched 
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FUNCTION/CAPABILiTY TABLE FOR IAS BASE SYSTEM 



TECHNOLOGICAL 

CAPABILITIES 


FUNCTIONS 


Automate Mapping 


Automate Overlays 


Automate Info Exchange 


Selectable level of Map Detail 


00 


00 




7oom-ln/Zoom*Out Capability 


w 






DMA Product Compatibility 


w 




® 


Scanned Map Capability 


X 






3-D Map Capability 


X 






Generate Overlays 




C^O 




Disseminate Overlays 




w 


0 


3-D Overlay Capability 




X 




Large Color Print Capability 




(X) 




Large Screen Display 




X 




LAN Connectivity 






X 


Single Channel Radio Connectivity 






0 _ ^ 


Switcned Backbone Connectivity 






X 1 



X - Denotes that the Technological Capability is required to automate that Column s Function 
Denotes that the System possesses this Technological Capability 



Figure 19: Function/Capability Table for the Intelligence Analysis System 

Backbone connectivity is required. Similarly, in the case of IAS, to provide the required 
automated support to the mapping function, scanned maps and three-dimensional maps 
technological capabilities are required. To meet the automation of overlays requirement, 
a three-dimensional overlay capability and large screen display capability is required and 
to automate the information exchange function, LAN connectivity and Switched 
Backbone connectivity is required. 

Through cooperation of technical, operational, and programmatic experts, 
viable timed patterns of adding these capabilities can be developed. The table in Figure 
20 summarizes the viable paths that are used in this illustration. Only two paths for each 
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THE VIABLE PATHS 



TECHNOLOGICAL 

CAPABILITIES 


ALTERNATIVE BASE SYSTEMS 


NTCS - A 


IAS 


PATH 1 


PATH 2 


PATH 3 


PATH 4 


Scanned Map Capability 


YEAR1 


YEAR 2 


YEAR1 


YEAR 2 


3-D Map Capability 


YEAR 2 


YEAR 4 


YEAR 2 


YEARS 


3-D Overlay Capability 


YEARS 


YEAR 4 


YEAR 3 


YEAR 4 


Large Screen Display 


N/A 


N/A 


YEAR 4 


YEARS 


LAN Connectivity 


YEAR 4 


YEAR 1 


YEAR 4 


YEAR1 


Switched Backbone Connectivity 


YEARS 


YEARS 


YEAR S 


YEAR1 



NOTE; Contents of table denotes what year a particular path will obtain that Technological Capability 

Figure 20: The Viable Paths 

alternative base system has been chosen for simplicity, although there may actually be 
many viable paths. The four paths will become the Candidate Paths for the evaluation. 
The table in Figure 20 indicates for each alternative base system’s path, what year a 
particular technological capability will be added to the base system. As discussed in 
Chapter HI, selection of these candidate paths require experts in many disciplines to 
agree on what can be considered viable upgrade paths. One method would be to charter 
an independent agency to perform this task. With the candidate paths determined, the 
evaluator can move on to the next step of getting the discounted values and costs of each 
candidate path. 

3. Get Values and Costs 

The third step of the framework involves assigning functionally derived 
values and capability derived costs to each candidate path at discrete time intervals. 
These values and costs are then discounted to present values and costs and added 
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together. The output of this step is a single discounted value and a single discounted cost 
associated with each candidate path. 

Figure 21 graphically illustrates what each candidate path looks like. For 
simplicity, only a time span of five years is chosen. It is clear that each candidate path 
is simply a timed insertion of technological capabilities. 



YEAR ■ 



alternative 

BASE SYSTEMS 



THE CANDIDATE PATHS 



INCREMENTAL UPGRADE PATHS TOWARD THE TARGET 



PLANNING 

HORIZON 






A - Scanned Map Capability 


LEGEND FOR THE 


B - 3-D Map Capability 


TECHNOLOGICAL CAPABILITIES 


C - 3-D Overlay Capability 


THAT ARE ADDED 


D - Large Screen Display 




E - LAN Connectivity 




F - Switched Backbone Connectivity 



Figure 21: The Viable Candidate Paths 



As technological capabilities are added, the system will periodically obtain enough 
technological capabilities to provide the required level of automated support to one or 
more of the target system functions. Each candidate path will eventually succeed in 
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reaching the required level of automation stated in the definition of the target system 
functions and capabilities. 

The overall discounted value of a candidate path is the sum of the discounted 
values of each function. The discounted value of a function depends on when (e.g. , what 
year) that function is successfully automated in a candidate path. A simple method for 
discounting the value of a function is illustrated in Figure 22. The graph shows the 
relationship between the value of a function and the year in which it is added to the 
candidate path. If the system obtains a function today, it receives the full value of that 
function (one). Likewise, if the function is not automated until say 10 years from now, 
it only receives halP the determined value of the function (one-half). How the graph 
behaves in between the present and the planning horizon depends on the time utility or 
temporal importance the users place on receiving a particular function^. Functions that 
are added sooner will contribute more value to the overall value of a candidate path than 
if they were added later. 

To compute the discounted value of the functions, the linear relationship in 
Figure 22 is used for simplicity. This yields the following equation for determining the 
discounted value of a function: 



^ The residual value of one-half was arbitrarily chosen by the authors. Evaluators should 
feel free to pick an appropriate residual or terminal value of obtaining a particular function. 

^ A thorough discussion on Utility theory can be found on page 258 of Reference 29. 



75 



( 5 ) 



Where DV; is the discounted value of the i* function, 1 is the value of each 
function at t = 0, and t is the year or time period that the candidate path successfully 
automates the function i. 



DISCOUNTING OF FUNCTIONS 




YEAR IN WHICH SYSTEM GAINS FUNCTION 



Figure 22: How the Value of Functions are Discounted to the Present 
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To find the overall discounted value of the candidate path, the individual 
discounted values of each function are simply added. The following equation will be 
used: 

N 

ODV='^ DV^ ( 6 ) 

i*l 

Where ODV is the overall discounted value of the candidate path, i is a 
counter for the individual functions, N is the total number of functions, and DVj is the 
discounted value of the i* function. 

Costs of the candidate paths that the framework uses are the cost of the 
alternate base system if bought today and the cost of adding a particular technological 
capability to given base system. Costs of adding a particular technological capability 
may be different for each alternative base system because each system may require 
different combinations of hardware and/or software to provide the required level of 
automation depending on the current configuration of a given base system. Figure 23 
shows the estimated costs of adding the needed technological capabilities to the two 
alternative base systems chosen. 

Discounted costs of adding technological capabilities are computed using the 
standard discounting function: 
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COST OF PROVIDING ADDITIONAL TECHNOLOGICAL CAPABILITIES 



TECHNOLOGICAL 

CAPABILITIES 


ALTERNATIVE BASE SYSTEMS 


NTCS-A 


IAS 


Scanned Map Capability 


$400,000 


$400,000 


3-D Map Capability 


$ 207,000 


$207,000 


3-D Overlay Capability 


$ 207,000 


$ 207,000 


Large Screen Display 


N/A 


$ 355,000 


LAN Connectivity 


$ 100,000 


$ 60,000 


Switched Backbone Connectivity 


$473,000 


$ 120,000 



NOTE: Contents of table denotes cost of adding the Technological Capability to a particular Base System. 
Costs were estimated using data from the COEA Final Report (Draft), Appendix K (Costs) 



Figure 23; Technological Capabilities and their Costs 



DC,= 






(7) 



,(l+r)y_ 

Where DCj is the discounted cost of adding the j* technological capability, 
r is the discounting factor or interest rate, y is the year or time period, and Cj is the cost 
of adding the j* technological capability to the system. 

To calculate the overall discounted cost of the candidate path, the initial cost 
of the alternative base system is added to the discounted cost of each technological 
capability that is added to the candidate path. The following equation is used to compute 
the overall discounted cost of a candidate path: 



M 

ODC=IC+Y^DCj ( 8 ) 

Where ODC is the overall discounted cost of a candidate path, ICj is the 
initial cost of buying the alternative base system, M is the total number of technological 



78 



capabilities that are added to a candidate path, and DCj is the discounted cost of adding 
the j* technological capability. 

Figure 24 illustrates how the above calculations are used to calculate the 
overall discounted value and cost of the first candidate path. 



VALUE AND COST OF A CANDIDATE PATH 



YEAR 


0 


1 


2 


3 


A 


5 
















CANDIDATE PATH nTCS - A — 


A 


B 


C 


E 


F 
















FUNCTIONS AUTOMATED 


None 


None 


Mapping 


Overlays 


None 


Info Exch 


VALUE 


0 


0 


1 


1 


0 


1 


DISCOUNTED 

VALUE 


1 

0 ' 0 
1 


0.9 


0.85 


0 

I 


0.75 




COST 


1500K 


400IC 


207K 


207K 


100K 


473K 


DISCOUNTED 

COST 


1500K 


363.6K 


171K 


155.5K 


68.3K 


293.7K 



OVERALL DISCOUNTED VALUE OF THE CANDIDATE PATH = 0.9 + 0.85 + 0.75 = Z5. 

OVERALL DISCOUNTED COST OF THE CANDIDATE PATH = 1500 + 363.6 + 171 + 155.5 + 68.3 t 293.7 

= 2552.1K 

Figure 24: Computation of the Discounted Value and Cost of a Candidate Path 



The procedure for finding the overall discounted value and cost of a candidate 
path is simple. The first step involves determining when (or at which time periods) the 
candidate path will succeed in automating the functions of the target system. As can be 
seen in Figure 24, the first candidate path succeeds in providing the required automated 
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support to the mapping function in year two. The overlay function is obtained in year 
three and the information exchange function is obtained in year five. The second step 
requires the use of Equation (1) to compute the discounted value of each of the functions. 
The third step uses Equation (3) to calculate the discounted costs of the technological 
capabilities that are added to the system. The fourth and fifth steps use Equations (2) 
and (4) to compute the overall discounted value and cost of the candidate path. As can 
be seen from Figure 24, calculations for the first candidate path yield a discounted value 
of 2.5 and discounted cost of 2552. IK. Figure 25 shows the results of doing these 
calculations on the remaining candidate paths. 

The next step of the framework discusses the selection of a candidate path 
using the values and costs that were calculated in this step. 



DISCOUNTED VALUES AND COSTS OF THE CANDIDATE PATHS 





ALTERNATIVE BASE SYSTEMS 


NTCS - A 


IAS 


PATH1 


PATH 2 


PATH 3 


PATH 4 


DISCOUNTED VALUE 


2.5 


2.35 


2.5 


2.55 


DISCOUNTED COST 


2552.1K 


2498K 


254 8K 


21115K 



Figure 25: The Discounted Value and Cost of Each Candidate Path 
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4. Select 



The last step of the freimework involves selecting the best candidate path. In 
this kind of decision, the "best" candidate path is the one that maximizes value subject 
to cost, resource, and risk constraints^^. The rule or problem is stated as: 

Maximize: Value 

Subject to: • Cost 

• Resource 

• Risk 

An easy procedure for selecting the best candidate path given the data like 
that in Figure 25, is to first remove the candidate paths that don’t satisfy at least one of 
the constraints from consideration. For the purpose of the illustration, say a budget of 
2500K has been allocated for the system and that all candidates meet the resource and 
risk constraint. From Figure 25, candidate paths one and three exceed the established 
cost constraint, so they will not be considered. The next step is to select from the 
remaining candidate paths, the one that has the greatest value. For the illustration, 
candidate path four is selected^. 



While this framework does not expand on the resource and risk constraint, they are still 
important issues that deserve a fair amount of attention for an actual evaluation. 

Candidate path four had the greatest value because it succeeded in automating some of 
the functions sooner than the other paths. It also had the least cost because the more expensive 
technological capabilities were added later in its path, which allowed them to take advantage of 
the discounting. 
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C. CONCLUSIONS 



The illustration is intended only to give the reader a general idea of how to apply 
the concepts and procedures of this framework. For that purpose, the illustration is an 
extremely simplified one. Evaluations of actual systems would begin with a much bigger 
function/capability table for the definition of the target system functions and capabilities 
and would require more data. Nonetheless, the steps of the framework are fairly simple 
to follow and flow logically from one step to the next. The tables and data produced by 
this framework provide the decision makers with invaluable insight into how the various 
alternatives will change over time and may highlight evolutionary issues that have been 
overlooked in the past. This framework will result in decisions that have taken into 
account the difficult, but ever present, temporal component of evolving C^ systems. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



A. SUMMARY 

1. The C^ Systems Procurement Environment 

Chapter II presented a discussion of the technology initiatives that will impact 
C^ systems. The Evolutionary Acquisition concept was introduced and topics such as 
Non-Developmental-Items, Commercial-Off-the-Shelf products, and open architecture 
standards were presented. It is important that the procurement environment in which C? 
systems are procured be understood by the evaluators. Important factors of the 
procurement environment that effect C^ systems include; the recent increased rate of 
technological change, the mandated use of the Evolutionary Acquisition concept, the use 
of NDI and COTS products, and the evolving open architecture standards. 

2. Current Frameworks 

Chapter II also presented a cross-section of some of the current C^ system 
evaluation frameworks. The Mission-Oriented Approach, the Modular Command and 
Control Evaluation Structure, and the COEA team’s evaluation approach were discussed 
and their applicability to current C^ systems evaluation highlighted. None of these 
frameworks or methodologies specifically deal with the temporal component of C^ 
systems. 
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3. The New Framework 



Chapter HI presented a new framework that focuses the evaluation of 
alternatives on their evolutionary upgrade paths. The framework presents a method that 
could be useful to decision makers in choosing between alternative systems. The 
framework contains four steps: 

1. Define target system functions and capabilities. 

2. Define all viable upgrade paths from each alternative base system to the target 
system; each path becomes a candidate path. 

3. Develop discounted value and discounted cost for each candidate path. 

4. Select the candidate path that maximizes value subject to stated cost, resource, 
and risk constraints. 

Methods and procedures for accomplishing each step was presented. 

4. The niustration 

Chapter IV provided an illustration of the framework. The illustration 
focused on the Marine Corp’s TCO system described in Chapter I. The illustration 
clarified how the methods of the framework can be applied. 

B. CONCLUSIONS 

1. The C^ Systems Procurement Environment 

The following conclusions can be made in regard to the environment in which 
C^ systems are procured: 
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1. That systems must capitalize on emerging technologies to remain mission 
capable. 

2. That systems will incorporate evolutionary upgrades throughout their useful 
life cycle if procured through evolutionary acquisition. 

3. That most of these evolutionary upgrades will be composed of NDI or COTS 
products that adhere to "open system" standards. 

4. That current evaluation frameworks do not base their evaluations on the 
temporal component of systems. 



2. The Framework as an Effective Tool for Evaluation 

The new framework presented here offers an alternative approach to 
systems evaluations. The framework’s methods for dealing with upgrade paths can be 
widely applied to many systems. systems of today and in the future will constantly 
change to keep up with state-of-the-art technologies. This aspect, called the temporal 
component, is directly addressed by this framework. 

This framework can be a very useful tool for evaluating systems or 
subsystems that will undergo many evolutionary upgrade changes throughout their useful 
life cycle. The author concludes that evaluations of alternatives can be based on 
cost/benefit analysis performed on the perceived future upgrade paths of the alternatives. 

3. The TCO Problem 

The TCO program will no doubt go through many changes during its life 
cycle. The concept is a valid one and it is greatly needed to support the warfighters in 
today’s environment. 
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It is almost certain that some new baseline system will be bought to fulfill the 
TCO requirements. The next upgrade to TCO will become a new baseline system. This 
baseline system will form the core on which evolutionary upgrades will be incrementally 
added during its useful life cycle. Several different acquisition strategies are currently 
being considered by the project office, but one thing is certain about the program, many 
periodic upgrades will be integrated into the system. At each decision point, choices will 
have to be made as to which upgraded product to buy. This framework could be used 
at these subsequent decision points to help the USMC pick the "best" product. 

C. RECOMMENDATIONS 

This framework represents an initial effort at basing the evaluation of alternatives 
on their future evolutionary upgrade paths. General concepts and procedures were 
introduced. Areas that could benefit greatly by further research include: 

1. More streamlined methods for determining target system functions and 
capabilities. 

2. Methods that more accurately predict future upgrade technological capabilities 
and costs. 

3. Procedures that would expand the framework to include evaluations of the 
uncertainty and risk issues. 
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APPENDIX A: GLOSSARY 



ACE 


Aviation Combat Element 


ACMC 


Assistant Commandant of the Marine Corps 


ADM 


Acquisition Decision Memorandum 


ADPE-FMF 


Automatic Data Processing Equipment-Fleet Marine Force 


AE 


Acquisition Executive 


AFATDS 


Advanced Field Artillery Tactical Data System 


AHP 


Analytical Hierarchy Process 


AIC 


Automated Information Center 


AOA 


Amphibious Operational Area 


APO 


Acquisition Project Officer 


ARC 


Atlantic Research Corporation 


ASD 


Assistant Secretary of Defense 


ASP 


Acquisition Strategy Plan 


ASPO 


Acquisition Sponsor Project Officer 


ATACCS 


Army Tactical Automated Command and Control System 


ATCCS 


Army Tactical Command and Control System 


ATDL-1 


Army Tactical Data Link-1 


ATO 


Air Tasking Order 


AUTODIN 


Automatic Digital Network 


C^ 


Command and Control 


C^MP 


Command and Control Master Plan 


C^ 


Command, Control, and Communications 


C^I 


Command, Control, Communications, and Intelligence 


C^I 


Command, Control, Communications, Computers, and Intelligence 
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Command, Control, Communications, Con 
Intelligence, and Interoperability 


CATF 


Commander Amphibious Task Force 


CE 


Command Element 


CECOM 


U.S. Army Communications-Electronics Command 


CEO 


Chief Executive Officer 


CG 


Commanding General 


CIM 


Corporate Information Management 


CIP 


Combat Information Processor 


CMC 


Commandant of the Marine Corps 


COC 


Combat Operations Center 


COEA 


Cost and Operational Effectiveness Analysis 


COTS 


Commercial-Off-The-Shelf 


CP 


Command Post 


CSI 


Command Systems Incorporated 


CSSE 


Combat Service Support Element 


CTIS 


Command Tactical Information System 


DCA 


Defense Communications Agency 


DISA 


Defense Information Systems Agency 


DMA 


Defense Mapping Agency 


DoD 


Department of Defense 


DOS 


Disk Operating System 


DPM 


Deputy Program Manager 


EA 


Evolutionary Acquisition 


EPLRS 


Enhanced Position Location and Reporting System 


FIPS 


Federal Information Processing Standard 


FMF 


Fleet Marine Force 


GCE 


Ground Combat Element 


GOR 


General Operational Requirement 
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GOSIP 


Government Open System Interconnection Profile 


GUI 


Graphical User Interface 


HQMC 

IAS 


Headquarters Marine Corps 
Intelligence Analysis System 


lEC 


International Electrotechnical Committee 


ISO 


International Standards Organization 


JTIDS 


Joint Tactical Information Dissemination System 


LAN 


Local Area Network 


MAGTF 


Marine Air Ground Task Force 



MARCORSYSCOM Marine Corps Systems Command 



MCASS 


MTACCS Common Application Support Software 


MCCDC 


Marine Corps Combat Development Command 


MCES 


Modular Command and Control Evaluation Structure 


MCHS 


MTACCS Common Hardware Support 


MCOTEA 


Marine Corps Operational Test and Evaluation Activity 


MCS 


Maneuver Control System 


MCTSSA 


Marine Corps Tactical Systems Support Activity 


MOA 


Mission Oriented Approach 


MOE 


Measure of Effectiveness 


MOFE 


Measure of Force Effectiveness 


MOP 


Measure of Performance 


MORS 


Military Operations Research Society 


MEF 


Marine Expeditionary Force 


MEU 


Marine Expeditionary Unit 


MIFASS 


Marine Integrated Fire and Air Support System 


MNS 


Mission Need Statement 


MTACCS 


Marine Corps Tactical Automated Command and Control System 


NDI 


Non-Developmental-Item 


NMSD 


National Military Strategy Document 
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NTCS-A 


Naval Tactical Command System - Afloat 


O&S 


Operations and Support 


0MB 


Office of Management and Budget 


PM 


Program Manager 


POSIX 


Portable Operating System Interface - UNIX 


R&D 


Research and Development 


RDT&E 


Research Development Testing & Evaluation 


SMART 


Simple Multi- Attribute Rating Technique 


SOCEX 


Special Operations Command Exercise 


TCIM 


Tactical Communications Interface Module 


TOO 


Tactical Combat Operations system 


TNS 


Tactical Network Server 


US 


United States 


USMTF 


United States Message Text Formats 


USPACOM 


U.S. Pacific Command 


WAN 


Wide Area Network 
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